This invention relates generally to programmable logic devices (PLDs), and more particularly to a method and system for generation and evaluation of architectures for such devices.
PLDs are a widely used form of integrated circuit because of the flexibility provided by their customizable nature. In general, PLDs include field programmable gate arrays (FPGAs), complex programmable logic devices (CPLDs), simple programmable logic devices, and laser programmable devices. Architecturally, a PLD includes logic blocks and input/output (I/O) blocks which are connectable through a programmable interconnect structure.
A typical PLD is an integrated circuit chip that, wholly or in part, includes an array of one or more logic blocks, I/O blocks, and a programmable routing or interconnect network. The interconnect network can be programmed by a user to provide a connection between the logic and I/O blocks to achieve a desired logic function. A PLD can be a standalone device or embedded in a larger integrated circuit such as an ASIC or the like. Exemplary forms of such embedded PLDs are disclosed in U.S. Pat. Nos. 5,687,325 and 5,825,202.
Logic blocks may have a fixed logic function or may also have programmable functionality and programmable interconnect networks. Logic blocks may be further broken down into sub-blocks or grouped together as a cluster of logic blocks. These blocks may also include I/O circuits that can be connected to external circuits or to other parts of the chip as in the case of an embedded PLD. The I/O blocks are typically arranged at the periphery of a chip.
A PLD is typically arranged as a regular array of logic blocks, each of which may be identical or may be one of several different types (such as memory blocks, look-up table based blocks, p-term based blocks, etc.). The conductors of the programmable interconnect network are typically arranged along rows and columns defined by the array of logic blocks, as shown in FIG. 1.
The architecture of a PLD specifies the structure of its logic blocks, I/O blocks, and programmable interconnect network. In order to develop a high-quality PLD architecture, the PLD designer should evaluate the impact and utility of a wide range of architectural decisions and trade-offs. The performance of a PLD is typically judged on the basis of operational parameters of circuits implemented in the PLD. These operational parameters include    (1) speed of circuits implemented in the PLD,    (2) semiconductor or silicon area required to implement a given circuit in the PLD, (3) power dissipation of the PLD after it has been programmed, (4) reliability, and (5) routing flexibility.
The typical procedure for evaluating different architectures is shown in FIG. 2. A set of benchmark circuits is implemented in each PLD architecture (or architecture variant) of interest, and the operational parameters of the circuits are analyzed. Generally, PLD designers prefer to experiment with as wide a variety of PLD architectures as possible in order to determine the architecture or class of architectures that best meets the operational parameters of interest.
However, in order to implement circuits in a PLD architecture of interest, the PLD designer requires a method of describing the PLD architecture to a CAD toolset. There are two basic components of a PLD architecture: the routing architecture which describes the routing resources or programmable interconnect network, and the logic (or function) block architecture. Consider first the problem of describing the PLD routing architecture.
To specify a PLD architecture in its entirety, the location of every switch, routing wire, and logic and I/O block pin should be specified. The routing wires and logic and I/O blocks that can be interconnected by programmable switches should also be specified, as well as the delay of every programmable switch, routing wire, and circuit path through a logic block. This is an enormous amount of data—typically tens to hundreds of megabytes (MB) in size. Accordingly, it is not practical for a PLD architect to specify this data directly for every PLD architecture in which he or she is interested.
The most straightforward way of describing a PLD routing architecture is to create a directed graph (also called a routing-resource graph) that fully specifies all the connections that may be made in the routing of a circuit in the PLD. In essence, this requires the PLD designer to describe where every switch, interconnect wire, and logic and I/O block connection pin is located. This description should specify which routing wires, logic blocks, and I/O blocks can be interconnected by programmable switches. The description should also specify the delay of every programmable switch, interconnect wire, and circuit path through a logic block in the entire PLD. This is a very general representation of a PLD and is typically the data structure used internally by the routing tool. However, it is not very practical to specify this routing-resource graph manually because the routing-resource graph for a typical PLD requires an enormous amount of data—typically in the tens to hundreds of MBs of memory in size. Essentially, this is too low-level a description for a PLD architect to use conveniently.
A more practical approach is to design manually a basic tile (which has a single logic block and its associated routing), and create a program to automatically replicate and stitch together this tile into a routing-resource graph describing the entire PLD routing architecture. However, even the manual creation of a basic tile can be too time-consuming for most PLD architectures. A typical tile contains several hundred programmable switches and wires, so it can take hours or days to describe a single tile. Furthermore, the hand-crafted tile is severely limited in the PLD interconnect or logic block resources that may be varied—for example, a hand-crafted tile is generally designed for one value of the routing channel width, W (the number of routing tracks in a channel). In many architecture experiments, W is varied in order to see how routable a given PLD architecture is, or to determine the minimum value of W that allows some desired fraction of application circuits (say 95%) to route successfully. With a tile based approach, the PLD designer should hand-craft different tiles for each different value of W to be tested. A PLD designer will often wish to investigate hundreds of different PLD architectures and tens of W values for each of these architectures. The net result is that the PLD designer is required to create thousands or tens of thousands of different basic tiles.
There has been some prior work in describing PLD routing at a higher level of abstraction. One known FPGA router is for use with island-style FPGAs. In order to quickly investigate FPGAs with different numbers of routing switches, all the code that interacted with switch patterns is localized to two routines, Fc( ) and Fs( ). By rewriting these two routines, the FPGA designer can target the router to an FPGA with different switch patterns. A later router used the same method to allow re-targeting to different FPGAs.
In a known CAD system, an FPGA's routing is described by means of WireC schematics—essentially schematics annotated with C-language-like code that describes switch patterns. This CAD system can convert the WireC schematics into routing-resource graphs for use by its FPGA router.
While these known routers and CAD system all reduce the labor required to specify a PLD architecture, they still require considerable hand-crafting effort. Instead of specifying every switch in a basic tile of an FPGA, these systems allow PLD designers to write software code (in either C or WireC) to generate all the switches in a basic tile. If the PLD designer writes sufficiently general code, it may be possible to change some interconnect and logic resources, such as the channel width W, and have the basic tile adapt properly. However, it is the user's task to specify this in often non-obvious code.
The second portion of a PLD architecture description details each type of function block (logic or I/O block) contained in the PLD. Both the interface to the PLD routing of each function block (i.e., a list of the inputs and outputs of the block) and a description of the logic functions that can be implemented by the function block should be provided. A concise method for providing this information is crucial to allow easy experimentation.
Also, timing and area model information for both the routing and function blocks may be included in the PLD architecture description to allow the CAD tools to estimate the speed achieved by the circuits in this architecture and the layout area consumed by the architecture.
Accordingly, there is a need for a method and system that reduces the labor involved in describing a complete PLD architecture and that allows the easy variation of many interconnect and logic resource parameters of the architecture.